Many existing software products may be rich in functionality, but not secure enough to be exposed in less-secure deployment environments (such as those utilizing the public Internet). Accordingly, it is necessary to decide whether exposure of such products to insecure environments is worth the cost. If one deploys a product in an insecure environment, then there is a non-zero risk of malicious access or at least attempted malicious access, and this level of risk is unacceptable in many situations, such as when the product exposes application programming interfaces (APIs) that facilitate access to sensitive information (e.g., private customer data). On the other hand, simply preventing deployment of a product walls off possibly important users or clients from having access to the rich functionality provided by the product, which is itself a suboptimal result. A middle ground is thus needed.
In particular, a mechanism is needed to expose only a subset of the functionality of a product and with various levels of authentication and authorization security mechanisms. One response to this problem is to manually modify the security mechanisms of a software product for a particular deployment environment. By doing so, one could theoretically overcome the hurdles noted above, but this solution has its own problems. For instance, this solution would have to be implemented for all application program interfaces (APIs), not only the ones needed for integration into the environment. Moreover, manually updating each software product is a costly approach, especially when the software product is large and exposes many APIs. As a result, a less costly mechanism is needed that would limit which APIs of a software product are available for which deployment environment and with which security options.